Пересказ: КАК СКАЗАТЬ НЕТ СЛАБОМУ КОДУ — LLM-интеллект в разработке

Источник: https://t.me/SberAIScience/4135

Автор: Кирилл Меньшов, старший вице-президент и руководитель блока «Технологии» Sber

Парадокс генеративного ИИ в разработке

Генеративный ИИ (ChatGPT, Claude, GigaChat) значительно ускоряет разработку, но код, который выглядит идеально внешне, может содержать критические ошибки:

# LLM может сгенерировать такой код...
def process_payment(amount, account):
    if amount > 0:
        account.balance -= amount  # Выглядит хорошо, но где валидация?
        return True                # А обработка ошибок?
    return False

Проблема: LLM хорошо воспроизводит типовые шаблоны, но не понимает архитектуру вашей системы, контекст задачи или корректность алгоритма.

Концепция: LLM-интеллект

Меньшов вводит новый инженерный навык — LLM-интеллект (LLM Intelligence):

Это умение понимать «мышление» модели: где она сильна, где ошибётся и как направлять её к правильному результату.

Аналогия: если раньше разработчик работал с кодом один, то теперь он управляет LLM-помощником, как опытный senior работает с junior.

6 инженерных практик для работы с LLM

1. Относитесь к LLM как к джуниор-разработчику

❌ Неправильно:
prompt = "Напиши функцию для обработки платежей"

✅ Правильно:
prompt = """
Напиши функцию calculate_tax для подсчёта налога.

Требования:
- На входе: сумма (float), тип налога (str: 'НДС', 'УСН')
- На выходе: размер налога (float)
- Пограничные случаи:
  * Сумма < 0 → ошибка
  * Неизвестный тип → ошибка
  * НДС 18% от суммы
  * УСН 6% или 15% в зависимости от доход

Структура ответа:
def calculate_tax(amount: float, tax_type: str) -> float:
    # ...

Обязательно добавь docstring и примеры использования.
"""

Правило: давайте спецификации, контекст, пограничные случаи и всегда делайте код-ревью.

2. Сначала интерфейсы и типы, потом реализация

# Шаг 1: определяем контракт (interface)
from typing import Protocol

class DataProcessor(Protocol):
    def process(self, data: List[Dict]) -> List[Dict]:
        """Обработать данные и вернуть результат"""

    def validate(self, data: List[Dict]) -> bool:
        """Валидировать формат данных"""

# Шаг 2: просим LLM реализовать эту interface
prompt = """
Реализуй класс CSVDataProcessor, который удовлетворяет интерфейсу DataProcessor.
Используй pandas для работы с CSV.
"""

Это улучшает качество генерируемого кода, так как LLM видит структуру и контракт.

3. Ментальная карта сильных/слабых сторон модели

Создайте таблицу для каждой LLM, с которой работаете:

Задача	Сильна	Слаба	Уровень доверия
Генерация SQL	✅	-	85%
Рефакторинг	✅	-	80%
Архитектурные решения	❌	✅	20%
Обработка ошибок	⚠️	⚠️	50%
Оптимизация производительности	❌	✅	30%

Вывод: не делегируйте архитектуру, не рассчитывайте на оптимизацию, но можете использовать для генерации бойлерплейта.

4. Требуйте объяснений

Вы: "Почему ты выбрал именно эту структуру данных?"
LLM: "Потому что список имеет O(n) поиск, а дерево — O(log n).
      Для 10к элементов это критично."

Вы: "А есть ли граничные случаи?"
LLM: "Да, если данные отсортированы, то бинарное дерево не сбалансируется..."

Просите LLM объяснять решения — это помогает вам лучше понимать логику и ловить ошибки.

5. Слепая проверка перед коммитом

# Слепая ревью: проверить код БЕЗ сверки с исходным заданием
# Ищете ошибки в логике, обработке исключений, производительности
$ git diff --no-index original.py generated.py

# Вопросы при слепой ревью:
# - Все ли case-ы обработаны?
# - Есть ли утечки памяти?
# - Может ли код упасть при неверных входных данных?
# - Соответствует ли стилю проекта?

Зачем: LLM может сгенерировать код, который соответствует заданию, но содержит скрытые баги.

6. Архитектура остаётся за человеком

❌ Не делегируйте LLM:
- Выбор технологического стека
- Разбиение на микросервисы
- Выбор БД и индексов
- Дизайн API
- Обработка отказоустойчивости

✅ Используйте LLM для:
- Реализации алгоритмов
- Генерации CRUD операций
- Написания тестов
- Документации
- Рефакторинга существующего кода

Долгосрочный прогноз

В ближайшие 5–10 лет разработка с поддержкой ИИ станет отраслевым стандартом. Но:

Разница между инженерами будет определяться не тем, используют ли они ИИ, а тем, как хорошо они с ним работают.

Это похоже на эволюцию: когда интернет стал стандартом, разница была между теми, кто умел использовать поисковики, и теми, кто нет.

Практические выводы

LLM — это инструмент, а не замена: требует опыта и суждения
Качество ввода определяет качество вывода: хорошая спецификация = хороший код
Code review обязателен: всегда проверяйте code-generated код перед мержем
Калибруйте доверие: знайте сильные и слабые стороны инструмента
Фокус на высокоуровневые задачи: пусть LLM пишет рутину, вы думаете о большой картине